Overview
Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their
efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc. The
content framework provides a structural model for architectural content that allows the major work products that an
architect creates to be consistently defined, structured, and presented.
The content framework provided here is intended to allow TOGAF to be used as a stand-alone framework for architecture
within an enterprise. However, other content frameworks exist (such as the Zachman Framework) and it is anticipated
that some enterprises may opt to use an external framework in conjunction with TOGAF. In these cases, the content
framework provides a useful reference and starting point for TOGAF content to be mapped to other frameworks.
The Architecture Content Framework uses the following three categories to describe the type of architectural work
product within the context of use:
-
A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and
signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in
documentation form will typically be archived at completion of a project, or transitioned into an Architecture
Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.
-
An artifact is a more granular architectural work product that describes an architecture from a specific
viewpoint. Examples include a network diagram, a server specification, a use-case specification, a list of
architectural requirements, and a business interaction matrix. Artifacts are generally classified as catalogs
(lists of things), matrices (showing relationships between things), and diagrams (pictures of things). An
architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture
Repository.
-
A building block represents a (potentially re-usable) component of business, IT, or architectural capability
that can be combined with other building blocks to deliver architectures and solutions.
Building blocks can be defined at various levels of detail, depending on what stage of architecture development
has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline
description. Later on, a building block may be decomposed into multiple supporting building blocks and may be
accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".
-
Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of
Solution Building Blocks (SBBs). For example, a customer services capability may be required within an
enterprise, supported by many SBBs, such as processes, data, and application software.
-
Solution Building Blocks (SBBs) represent components that will be used to implement the required
capability. For example, a network is a building block that can be described through complementary
artifacts and then put to use to realize solutions for the enterprise.
The relationships between deliverables, artifacts, and building blocks are shown in Relationships between Deliverables, Artifacts, and Building Blocks .
Figure: Relationships between Deliverables, Artifacts, and Building
Blocks
For example, an Architecture Definition Document is a deliverable that documents an architecture description.
This document will contain a number of complementary artifacts that are views of the building blocks relevant
to the architecture. For example, a process flow diagram (an artifact) may be created to describe the target
call handling process (a building block). This artifact may also describe other building blocks, such as the
actors involved in the process (e.g., a Customer Services Representative). An example of the relationships
between deliverables, artifacts, and building blocks is illustrated in Example - Architecture Definition Document .
Figure: Example - Architecture Definition Document
Content Metamodel
The content metamodel provides a definition of all the types of building blocks that may exist within an architecture,
showing how these building blocks can be described and related to one another. For example, when creating an
architecture, an architect will identify applications, "data entities" held within applications, and technologies that
implement those applications. These applications will in turn support particular groups of business user or actor, and
will be used to fulfil "business services".
The content metamodel identifies all of these concerns (i.e., application, data entity, technology, actor, and business
service), shows the relationships that are possible between them (e.g., actors consume business services), and finally
identifies artifacts that can be used to represent them.
Content Metamodel Overview shows an overview of the
content metamodel.
Figure: Content Metamodel Overview
Content Framework and the TOGAF ADM
The TOGAF ADM describes the process of moving from a baseline state of the enterprise to a target state of the
enterprise. The ADM will address a business need through a process of visioning, architecture definition,
transformation planning, and architecture governance. At each stage in this process, the ADM requires information as
inputs and will create outputs as a result of executing a number of steps. The content framework provides an underlying
structure for the ADM that defines inputs and outputs in more detail and puts each deliverable into the context of the
holistic architecture view of the enterprise.
The content framework should therefore be used as a companion to the ADM. The ADM describes what needs to be done to
create an architecture and the content framework describes what the architecture should look like once it is done.
Structure of Part IV
Part IV: Architecture Content Framework is structured as follows:
|